Multitenant database systems provide database services to sets of users, each set being referred to as a tenant. A multitenant database system is a database system designed to host multiple databases of multiple tenants while sharing underlying system resources, such as memory and background processes. Each of the multiple databases is hosted for a tenant and isolated from other of the multiple tenants. A multitenant database system is able to allocate more resources to any hosted database when additional resources are needed.
Efficient management of resources is essential in order to minimize operational cost and to ensure quality of service for tenants. Approaches for sharing resources include creating virtualized database servers, or nodes, in order to effectively provision resources. Node virtualization has eased resource provisioning by abstracting physical resources and creating virtualized resources on demand. If the peak resource demand of all tenants exceeds the amount of physical resources, the deployment is referred to as oversubscribed. One of the key challenges for multitenant databases is to efficiently manage oversubscribed resources without violating the promised level of performance to each tenant. Since resource needs of a tenant are often unpredictable and can be subject to sudden change, multitenant databases must be able to provide resources on demand to ensure good performance and quality for all tenants. For instance, load-balancing across servers may be necessary when oversubscription of resources occurs. In this scenario, a tenant may have to be migrated to another physical server, requiring that tenant's database be migrated to another physical server. Other instances which may require database migration include planned maintenance operations of a particular server. While maintenance operations may be scheduled during low traffic times, load-balancing can become necessary during peak traffic times.
Many database applications may not tolerate any downtime, large response time delays, or frequent failed requests as this may result in loss of revenue. In such a case, those databases may not be shut down before migration, but must be migrated online with as little disruption as possible. This migration scenario is referred to herein as a live migration. A key objective of a live migration is to minimize downtime, which is the period of time in which the database is not able to serve requests, and minimize the impact on service, by minimizing failed requests and response time delays.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.